[HEVC] x265.EXE: mingw builds

[Selur]

Problem seems to be that "http://sourceforge.net/projects/libpng/files/latest/download?source=files" doesn't exist any more
-> report the problem to jb-alvarado and wait for him to fix it
To make it clear, it's not really a media-autobuild_suite bug, but rather it's bug of the libpng sourceforge page,which now has a bunch of broken links.

[Ajaja]

C:/mingw/media-autobuild_suite-master/build32/x265-hg/source/common/threading.h:220:42: error: 'InitializeConditionVariable' was not declared in this scope

Bad changes. InitializeConditionVariable() needs Windows Vista at least. With -DCMAKE_CXX_FLAGS="$CFLAGS -D_WIN32_WINNT=0x0600" builds fine but does not run in WinXP.

[Selur]

added an entry to the issue tracker: https://bitbucket.org/multicoreware/x265/issue/44/threadingh-breaks-mingw-builds

[jb_alvarado]

I have fix the download link from libpng. And I use the Fix from Ajaja for x265. Let it me know when I need to change it again. He say that now it don't work in Windows XP anymore, so maybe someone have problems now.

[El Heggunte]

The incompatibility with MinGW under XP probably was introduced by patch 8ac1e11 which was commited on Feb 27:

threading: use a pthread conditional variable instead of semaphore

This allows more control over the exact behavior, removes the global nature
of the semaphore on some systems, and will allow the addition of a timed wait
to the Event class. It appears to resolve the deadlocks reproduced in the
pool test on Mac OS X; hopefully on Linux as well.

[Selur]

since I'm out with a flu (fever&co the whole thing), can some else test the "WIN_VER workaround" mentioned in the issue tracker?

[Vid01]

since I'm out with a flu (fever&co the whole thing), can some else test the "WIN_VER workaround" mentioned in the issue tracker?

Here is build 0.8+161-4c8ea265d55e for x64 built with MinGW GCC 4.7.1. The workaround works. The executable will not run on Windows XP though. It needs Vista or later.

Edit: @El Heggunte: It looks like the actual commit that caused the XP incompatibility is c0155c7.

[DarrellS]

I found the fix for libpng by changing address to file.

Ran the autobuild again overnight and woke to this error...

No package 'libxml-2.0' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables LIBXML2_CFLAGS
and LIBXML2_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target `install'. Stop.
-------------------------------------------------
build libbluray-git failed...
delete the source folder under '/build32' and start again
first close the batch window, then the shell window



Still no x265.exe yet but no error


Nice that there is an updated 64bit build but I was trying to build 32bit (I've never done this before) since I can't seem to find a working up to date 32bit build. The Russian guy's builds are way behind, the European guy's 32bit builds never work on XP and the Chrome guy doesn't do 32bit.

We need at least one good link on the front page for a working 32bit build instead of links to builds that don't work. Videohelp needs their own build so we don't have to go searching for a working build all over the internet.

[LigH.de]

And the american guy keeps ignoring my builds and doesn't care about names (how rude, but well, americans).

[Brazil]

I can't seem to find a working up to date 32bit build. The Russian guy's builds are way behind, the European guy's 32bit builds never work on XP and the Chrome guy doesn't do 32bit.

Builds from Selur and LigH.de are working fine even on XP.

[LigH.de]

Made in Germany

Well, I don't guarantee anymore for the latest builds I uploaded. I'll try later today when I have access to an XP system; v0.8+131 should still work, I hope, but if there are recent changes using unsupported APIs, I can't circumvent that easily.

[El Heggunte]

Edit: @El Heggunte: It looks like the actual commit that caused the XP incompatibility is c0155c7.

It seems you are right,
I've managed to compile commit b2617cb09a1a, which is 3-days old.

[DarrellS]

And the american guy keeps ignoring my builds and doesn't care about names (how rude, but well, americans).

For some reason, I couldn't find the link to your builds. There needs to be a link to it on the first page. I thought I'd try to build it myself so I didn't have to bug you and Selur for the latest build. I thought it would be simple with the autobuild that Selur linked to but it's more difficult than I assumed. The instructions on the first page on how to build x265 are pretty confusing to me.

Thanks for the updated build. I'll put your page in my favorites so I'll know where to find it. Your's and Selur's builds are the only ones that work for me.

[El Heggunte]

And the american guy keeps ignoring my builds and doesn't care about names (how rude, but well, americans).

For some reason, I couldn't find the link to your builds. There needs to be a link to it on the first page.

Already done

BTW, don't you have Visual Studio? Unless it's too old (2005 or 2008), it should be able to compile even the latest commits under XP (I think the "conditional variables problem" exists only for MinGW --- but I can be wrong).

[Ajaja]

[QUOTE=El Heggunte;2309618]

BTW, don't you have Visual Studio? Unless it's too old (2005 or 2008), it should be able to compile even the latest commits under XP (I think the "conditional variables problem" exists only for MinGW --- but I can be wrong).

Problem is not in compiler. Problem in InitializeConditionVariable function. Now x265.exe does not run in WinXP with message: "Procedure entry point InitializeConditionVariable could not be located in kernel32.dll".

http://msdn.microsoft.com/en-us/library/windows/desktop/ms683469%28v=vs.85%29.aspx
InitializeConditionVariable function
Minimum supported client: Windows Vista [desktop apps | Windows Store apps]

[Vid01]

BTW, don't you have Visual Studio? Unless it's too old (2005 or 2008), it should be able to compile even the latest commits under XP (I think the "conditional variables problem" exists only for MinGW --- but I can be wrong).

I would not really think you'd have much luck. I don't have a 32-bit XP system to test anymore, but the issue we are looking at is that a Windows API call used by the latest x265 revisions exists only in Windows Vista and later. MinGW highlights the problem because by default it's set to build for Win XP (its default _WIN32_WINNT definition is 0x502) and the problem API call is defined only for _WIN32_WINNT values of 0x600 (Windows Vista) and higher. MSVC probably has this macro already defined to Vista equivalent values so you never see anything wrong during build time. But even if you successfully build an executable with it on XP, chances are that you won't be able to run it because the kernel API functions needed will still be missing.

Until MulticoreWare come up with an alternative method to achieve the same results on XP as with the newer API calls on Vista and later, I would consider XP as a non-supported Windows platform for x265. The latest revision of the code that should be buildable/runnable for XP is 8dbcfae (last one before offending commit c0155c7).

[DarrellS]

Thanks for the link. Both your build and LigH.de latest builds (145 & 147) crash on my 3200x1800 encode. LigH.de's 131 build from the other day works.

I uninstalled VS 2005 because it kept popping up errors all the time.

[El Heggunte]

@ Ajaja && Vid01: thanks for well-informing the uninformed (a.k.a. me )

[DarrellS]

So x265_0.8+131 is the last build we can expect that supports XP? That's a shame since I don't really want to install W7 just for the x265 encoder. Especially since that competing HEVC encoder supports XP.

I was looking forward to seeing what changes were coming in Version 0.9.

[El Heggunte]

^ Well, it does appear x265 will not support XP anymore. At least I hope the MCW team will finally show some coherence by quitting the 32-bit environments altogether

But — assuming they prefer old prejudices to coherent behavior (as usual) ,
you could still set up and run a lightweight Linux distro in order to compile and use x265

[DarrellS]

I've got Windows 7 on another drive that I can plug into the top of my case but when I was installing it, I had trouble installing my scanner, printer and I believe my SIIG SATA card. Come to think of it, it never finished installing my MB drivers before it started crashing with blue screens so I just yanked it out and plugged my XP drive back in.

[LigH.de]

^ Well, it does appear x265 will not support XP anymore.

Correct: Patch 6547 (45af76338c8e) enforces a minimum Windows version of Vista via the CMake symbol _WIN32_WINNT_VISTA now.

3 weeks until the end of the XP life cycle, BTW. Further use at your own peril...

[vhelp]

hahh? first we loose a regularly updated x265 builds download repository, and now no more xp support with x265 ? and just because m$ass says no more support and that people can't stop talking about it ? sheesh. what rediculous and utter crap to inforce this on xp users just because of that. what crap. you can express or explain all the significances you want, but that won't change my mind.

i guess there is nothing else to do but retire from this x265 sw encoder, and instead, wait patiently until hauppauge or some other competitor creates the first hardware hevc/h265 encoder device, or find another hevc/h265 sw encoder that interests me.

thank you, to the people who are responsible or helped or had/have a hand in this inforcement

[El Heggunte]

3 weeks until the end of the XP life cycle, BTW. Further use at your own peril...

Thank you very-much for the "good-intentioned" F.U.D.

Seriously now, I am well aware of the limitations of Windows XP,
it's just that I cannot manage to like certain "post-post-modern features" of Windows Vista/7/8

(even more BLOAT, crippled file managers, gayish layouts, gayish icons, TrustedInstallers , etc Etc ETC).

[DarrellS]

Yeah, this Windows 7 is a crippled POS. The people who created it must have never used XP, 98SE or W2000 because even the most basic features of those OSs are nowhere to be found in Windows 7.

I was up all night trying to get programs installed and my magic jack working. Still have a lot of software to install. At least I've got it looking almost like Windows Classic but I was greeted a while ago to a message asking me if I wanted to keep on using classic shell trial or buy it. Nowhere did it say it was trialware when I downloaded and installed it.

[Selur]

because even the most basic features of those OSs are nowhere to be found in Windows 7.

Just out of curiosity: What are you missing? (I now a few things that have not made it to Windows 8, but I'm not missing anything in Windows 7)

I was up all night trying to get programs installed and my magic jack working.

Are you sure you are talking about Windows 7, afaik. MagicJack works fine with Windows 7.

[DarrellS]

My Computer for starters. Everytime I installed something, it asked if I wanted to make changes and when I clicked yes, it told me I didn't have permission but would install anyway and then tell me that the program I just installed did not install correctly and may not work. I'm the only user but for some reason, I can't get windows to start without having to enter a password. I unplugged Magic Jack and plugged it back in (I had tried this before) and it started up. Not sure whether it will start at startup until I restart my computer.

I was just thinking, how is using a 64bit build of x265 going to do me any good when I'm using 32bit Virtualdub? I guess we can still use the 32bit builds just not in XP.

[Selur]

Ah, okay you didn't understand basic user and rights management. (stuff Linux does from the start and Windows started with Vista)

I was just thinking, how is using a 64bit build of x265 going to do me any good when I'm using 32bit Virtualdub?

sure since, Virtual Dub uses the stand alone binary by piping it's output to the encoder, using 64bit x265 with 32bit Virtual Dub is no problem at all and encodings using a 64bit binary instead of a 64bit binary should be 10-15% faster, due to better/faster memory addressing.

[DarrellS]

Thanks! I did find how to put rest of the icons on the desktop (Computer, My Documents etc...).

I'll try the control userpasswords2 again and see if it works this time.

[Selur]

What was the last XP compatible revision?